chore: Added cryptography section to yellow paper#3647
Conversation
maramihali
left a comment
maramihali
left a comment
There was a problem hiding this comment.
nice work, i did a first pass and left a few comments/suggestions :)
|
|
||
| ## Honk | ||
|
|
||
| Honk is a variant of the PLONK protocol. Plonk performs polynomial testing via evaluating a polynomial relation is zero modulo the vanishing polynomial of a multiplicative subgroup. Honk performs the polynomial testing via evaluating, using a sumcheck protocol, that a relation over multilinear polynomials vanishes when summed over a boolean hypercube. |
There was a problem hiding this comment.
by checking instead of via evaluating seems more readable to me
|
|
||
| # Incrementally Verifiable Computation Subprotocols | ||
|
|
||
| An Incrementally Verifiable Computation (IVC) scheme describes a protocol that enables multiple successive proofs to evolve the value taken by some defined persistent state over time. |
There was a problem hiding this comment.
"multiple successibe proofs to evolve the value" reads a bit weird to me
There was a problem hiding this comment.
changed to something that might make more sense.
|
|
||
| Rollup-side, each "step" in the IVC scheme is a Honk proof, which are recursively verified. As a result, no protoocols other than Honk are required to execute rollup-side IVC. | ||
|
|
||
| We perform one layer of "proof-system compression" in the rollup. The final proof of block-correctness is constructed as a Honk proof. An UltraPlonk circuit is used to verify the correctness of the Honk proof, so that the proof that is verified on-chain is an UltraPlonk proof (verification gas costs are lower for UltraPlonk vs Honk). |
There was a problem hiding this comment.
(verification gas costs are lower for UltraPlonk vs Honk) - I would state briefly why this is the case
| The following sections list the protocol components required to implement client-side IVC. | ||
|
|
||
| ## Protogalaxy | ||
|
|
There was a problem hiding this comment.
I think this section should begin with defining what a folding scheme is
|
|
||
| ## Protogalaxy | ||
|
|
||
| The [Protogalaxy](https://eprint.iacr.org/2023/1106) protocol defines a folding scheme that enables instances of a relation to be folded into a single instance of a "relaxed" form of the original relation. |
There was a problem hiding this comment.
| The [Protogalaxy](https://eprint.iacr.org/2023/1106) protocol defines a folding scheme that enables instances of a relation to be folded into a single instance of a "relaxed" form of the original relation. | |
| The [Protogalaxy](https://eprint.iacr.org/2023/1106) protocol defines a folding scheme that enables instances of a relation to be folded into a single instance of the original relation, but in a "relaxed" form. |
|
|
||
| #### Elliptic Curve Virtual Machine (ECCVM) Subprotocol | ||
|
|
||
| The ECCVM is a Honk circuit with a custom circuit arithmetisation, designed to optimally evaluate elliptic curve arithmetic computations that have been deferred. It is defined over the Grumpkin elliptic curve |
There was a problem hiding this comment.
| The ECCVM is a Honk circuit with a custom circuit arithmetisation, designed to optimally evaluate elliptic curve arithmetic computations that have been deferred. It is defined over the Grumpkin elliptic curve | |
| The ECCVM is a Honk circuit with a custom circuit arithmetisation, designed to optimally evaluate elliptic curve arithmetic computations that have been deferred. It is defined over the Grumpkin elliptic curve. |
|
|
||
| #### Translator Subprotocol | ||
|
|
||
| The Translator is a Honk circuit with a custom circuit arithmetisation, designed to validate the input commitments of an ECCVM circuit align with the delegated computations described by a Goblin Plonk transcript commitment |
There was a problem hiding this comment.
| The Translator is a Honk circuit with a custom circuit arithmetisation, designed to validate the input commitments of an ECCVM circuit align with the delegated computations described by a Goblin Plonk transcript commitment | |
| The Translator is a Honk circuit with a custom circuit arithmetisation, designed to validate that the input commitments of an ECCVM circuit align with the delegated computations described by a Goblin Plonk transcript commitment. |
|
|
||
| ## Plonk Data Bus | ||
|
|
||
| The [Plonk Data Bus](https://aztecprotocol.slack.com/files/U8Q1VAX6Y/F05G2B971FY/plonk_bus.pdf) protocol enables efficient data transfer between two Honk instances within a larger IVC protocol. |
There was a problem hiding this comment.
A sentence about why this is needed would be good
|
|
||
| # Polynomial Commitment Schemes | ||
|
|
||
| The UltraPlonk, Honk, Goblin Plonk and Plonk Data Bus protocols utilize Polynomial Interactive Oracle Proofs as a core component, neccessitating the use of polynomial commitment schemes (PCX). |
There was a problem hiding this comment.
| The UltraPlonk, Honk, Goblin Plonk and Plonk Data Bus protocols utilize Polynomial Interactive Oracle Proofs as a core component, neccessitating the use of polynomial commitment schemes (PCX). | |
| The UltraPlonk, Honk, Goblin Plonk and Plonk Data Bus protocols utilize Polynomial Interactive Oracle Proofs as a core component, thus requiring the use of polynomial commitment schemes (PCS). |
|
|
||
| ## Inner Product Argument | ||
|
|
||
| The [IPA](https://eprint.iacr.org/2019/1177.pdf) PCS has worse asymptotics than KZG but can be instantiated over non-pairing friendly curves. |
There was a problem hiding this comment.
state this is needed for Grumpkin, if we are at it maybe we should also say we use cycle of curves somewhere?
|
|
||
| An Ethereum block consists of approximately 1,000 transactions, with a block gas limit of roughly 10 million gas. Basic computational steps in the Ethereum Virtual Machine consume 3 gas. If the entire block gas limit is consumed with basic computation steps (not true but let's assume for a moment), this implies that 1,000 transactions consume 3.33 million computation steps. i.e. 10 transactions per second would require roughly 33,000 steps per second and 3,330 steps per transaction. | ||
|
|
||
| An AVM circuit with 1 million steps can therefore accomodate approximately 300 transactions. Proof construction time must therefore be approximately 30 seconds to be able to prove all AVM programs in a block and achieve 10 tps. |
There was a problem hiding this comment.
Do I take this to mean we're now aiming for a single VM circuit to execute multiple app functions (rather than a VM circuit per app function)?
Benchmark resultsMetrics with a significant change:
Detailed resultsAll benchmarks are run on txs on the This benchmark source data is available in JSON format on S3 here. Values are compared against data from master at commit L2 block published to L1Each column represents the number of txs on an L2 block published to L1.
L2 chain processingEach column represents the number of blocks on the L2 chain where each block has 16 txs.
Circuits statsStats on running time and I/O sizes collected for every circuit run across all benchmarks.
MiscellaneousTransaction sizes based on how many contracts are deployed in the tx.
|
| | 2x2 rollup proving time | 1 2x2 rollup proof | 7.4 seconds | 0.74 seconds | | ||
| | 2x2 rollup memory consumption | 1 2x2 rollup proof | 128gb | 16gb | | ||
|
|
||
| To come up with the above estimates, we are targetting 10 transactions per second for the MVP and 100 tps for the "ideal" case. We are assuming both block producers and rollup Provers have access to 128-core machines with 128gb of RAM. Additionally, we assume that the various process required to produce a block consume the following: |
There was a problem hiding this comment.
@zac-williamson currently we have been assuming 32 -64 cores max as the perfomance benefit drops off after that.
See spreadsheet here: https://docs.google.com/spreadsheets/d/1cBBZZ_dyD0tiUmAdjoGbnLrk2H0oSmOgYubtZy9JTRU/edit#gid=1562975724
Secondly, ideally block producers (sequencers) can be run on 16 core 32gb machines as they will not be producing proofs.
|
|
||
| The first protocol to combine Plonk and the sumcheck protocol was [HyperPlonk](https://eprint.iacr.org/2022/1355) | ||
|
|
||
| Honk uses a custom arithmetisation that extends the Ultra circuit arithmetisation (not yet finalized) |
There was a problem hiding this comment.
I'd prob add something like "(e.g., it has special relations to efficiently prove Poseidon2 hashing)" but ofc this is not necessary.
There was a problem hiding this comment.
added mention of Poseidon2
| * Memory required to generate a user transaction proof | ||
| * Time to generate an Aztec Virtual Machine proof | ||
| * Memory required to generate an Aztec Virtual Machine proof | ||
| * Time to compute a 2x2 rollup proof |
There was a problem hiding this comment.
I know this "two-by-two" terminology has taken hold, but it's just wrong--IMO a two-by-two thing involves four things of the same type. The term does not indicate any kind of compression.
Motion to change to "2x1" or "2-to-1" 🙏🙏
|
|
||
| Rollup-side, each "step" in the IVC scheme is a Honk proof, which are recursively verified. As a result, no protoocols other than Honk are required to execute rollup-side IVC. | ||
|
|
||
| We perform one layer of "proof-system compression" in the rollup. The final proof of block-correctness is constructed as a Honk proof. An UltraPlonk circuit is used to verify the correctness of the Honk proof, so that the proof that is verified on-chain is an UltraPlonk proof. |
There was a problem hiding this comment.
You could link to this lovely explanation written by me and Luke
|
|
||
| #### Translator Subprotocol | ||
|
|
||
| The Translator is a Honk circuit with a custom circuit arithmetisation, designed to validate that the input commitments of an ECCVM circuit align with the delegated computations described by a Goblin Plonk transcript commitment. |
There was a problem hiding this comment.
Since you specified the ECCVM is defined over Grumpkin, maybe say here that the Translator is defined over BN254?
|
|
||
| ## Plonk Data Bus | ||
|
|
||
| When passing data between successive IVC steps, the canonical method is to do so via public inputs. This adds significant costs to an IVC folding verifier (or recursive verifier when not using a folding scheme). Public inputs for part of the proof and therefore must be hashed prior to generating Fiat-Shamir challenges. When this is performed in-circuit, this adds a cost linear in the number of public inputs (with unpleasant constants ~30 constraints per field element). |
There was a problem hiding this comment.
Can we change "Public inputs for part of the proof and therefore must be hashed prior to generating Fiat-Shamir challenges." to "Public inputs must be hashed prior to generating Fiat-Shamir challenges."?
|
|
||
| "MVP" = minimum standards that we can go to main-net with. | ||
|
|
||
| Note: gb = gigabytes (not gigabits, gigibits or gigibytes) |
There was a problem hiding this comment.
"gigifoo"
There was a problem hiding this comment.
I thought giga = 2^30 and gigi = 10^9 ?
|
|
||
| This sets the proof size limit to 819.2 kb per second per 100 transactions => 82 kilobytes of data per transaction. | ||
|
|
||
| As a rough estimate, we can assume the non-proof tx data will be irrelevant compared to 82kb, so we target a proof size of $80$ kilobytes for the MPV. |
|
|
||
| As a rough estimate, we can assume the non-proof tx data will be irrelevant compared to 82kb, so we target a proof size of $80$ kilobytes for the MPV. | ||
|
|
||
| To support 100 transactions per second we would rquire a proof size of $8$ kilobytes. |
There was a problem hiding this comment.
rquire
|
|
||
| The critical UX factor. To measure prover time for a transaction, we must first define a baseline transaction we wish to measure and the execution environment of the Prover. | ||
|
|
||
| As we build+refine our MPV, we want to avoid optimising the best-case scenario (i.e. the most basic tx type, a token transfer). Instead we want to ensure that transactions of a "moderate" complexity are possible with consuer hardware. |
|
|
||
| Note: this excludes network coordination costs, latency costs, block construction costs, public VM proof construction costs (must be computed before the 2x2 rollup proofs), cost to compute the final UltraPlonk proof. | ||
|
|
||
| To accomodate the above costs, we assume can budget 40% of block production time towards making proofs. Given these constraints, the following table describes maximum allowable proof construction times for a selection of block sizes. |
There was a problem hiding this comment.
"we assume can budget"
7 participants
Please provide a paragraph or two giving a summary of the change, including relevant motivation and context.
Checklist:
Remove the checklist to signal you've completed it. Enable auto-merge if the PR is ready to merge.